Efficient allocation of network resources, such as available network bandwidth, has become critical as enterprises increase reliance on distributed computing environments and wide area computer networks to accomplish business critical tasks. The widely-used TCP/IP protocol suite, which implements the world-wide data communications network environment called the Internet and is employed in many local area networks, omits any explicit supervisory function over the rate of data transport over the various devices that comprise the network. While there are certain perceived advantages, this characteristic has the consequence of juxtaposing very high-speed packets and very low-speed packets in potential conflict and produces certain inefficiencies. Certain loading conditions degrade performance of networked applications and can even cause instabilities which could lead to overloads that could stop data transfer temporarily.
In order to understand the context of certain embodiments of the invention, the following provides an explanation of certain technical aspects of a packet based telecommunications network environment. Internet/Intranet technology is based largely on the TCP/IP protocol suite. At the network level, IP provides a “datagram” delivery service—that is, IP is a protocol allowing for delivery of a datagram or packet between two hosts. By contrast, TCP provides a transport level service on top of the datagram service allowing for guaranteed delivery of a byte stream between two IP hosts. In other words, TCP is responsible for ensuring at the transmitting host that message data is divided into packets to be sent, and for reassembling, at the receiving host, the packets back into the complete message.
TCP has “flow control” mechanisms operative at the end stations only to limit the rate at which a TCP endpoint will emit data, but it does not employ explicit data rate control. The basic flow control mechanism is a “sliding window”, a window which by its sliding operation essentially limits the amount of unacknowledged transmit data that a transmitter is allowed to emit. Another flow control mechanism is a congestion window, which is a refinement of the sliding window scheme involving a conservative expansion to make use of the full, allowable window. A component of this mechanism is sometimes referred to as “slow start.”
The sliding window flow control mechanism works in conjunction with the Retransmit Timeout Mechanism (RTO), which is a timeout to prompt a retransmission of unacknowledged data. The timeout length is based on a running average of the Round Trip Time (RTT) for acknowledgment receipt, i.e. if an acknowledgment is not received within (typically) the smoothed RTT+4*mean deviation, then packet loss is inferred and the data pending acknowledgment is re-transmitted. Data rate flow control mechanisms which are operative end-to-end without explicit data rate control draw a strong inference of congestion from packet loss (inferred, typically, by RTO). TCP end systems, for example, will “back-off,”—i.e., inhibit transmission in increasing multiples of the base RTT average as a reaction to consecutive packet loss.
A crude form of bandwidth management in TCP/IP networks (that is, policies operable to allocate available bandwidth from a single logical link to network flows) is accomplished by a combination of TCP end systems and routers which queue packets and discard packets when some congestion threshold is exceeded. The discarded and therefore unacknowledged packet serves as a feedback mechanism to the TCP transmitter. Routers support various queuing options to provide for some level of bandwidth management. These options generally provide a rough ability to partition and prioritize separate classes of traffic. However, configuring these queuing options with any precision or without side effects is in fact very difficult, and in some cases, not possible. Seemingly simple things, such as the length of the queue, have a profound effect on traffic characteristics. Discarding packets as a feedback mechanism to TCP end systems may cause large, uneven delays perceptible to interactive users. Moreover, while routers can slow down inbound network traffic by dropping packets as a feedback mechanism to a TCP transmitter, this method often results in retransmission of data packets, wasting network traffic and, especially, inbound capacity of a WAN link. They can only explicitly control outbound traffic and cannot prevent inbound traffic from over-utilizing a WAN link. A 5% load or less on outbound traffic can correspond to a 100% load on inbound traffic, due to the typical imbalance between an outbound stream of acknowledgments and an inbound stream of data.
In response, certain data flow rate control mechanisms have been developed to provide a means to control and optimize efficiency of data transfer, as well as allocate available bandwidth among a variety of business applications. For example, U.S. Pat. No. 6,038,216 discloses a method for explicit data rate control in a packet-based network environment without data rate supervision. Data rate control directly moderates the rate of data transmission from a sending host, resulting in just-in-time data transmission to control inbound traffic and reduce the inefficiencies associated with dropped packets. In addition, bandwidth management devices classify network traffic and allow for explicit data rate control for flows associated with a particular traffic classification. U.S. Pat. No. 6,046,980, for example, teaches systems for managing bandwidth utilization at the network, transport and application layers in a packet-based network environment. Bandwidth management devices allow network administrators to specify policies operative to control and/or prioritize the bandwidth allocated to individual data flows according to traffic classifications. In addition, certain bandwidth management devices allow network administrators to divide available bandwidth into partitions. These partitions ensure a minimum bandwidth and/or cap bandwidth as to a particular class of traffic. An administrator specifies a traffic class (such as FTP data, or data flows involving a specific user or application) and the size of the reserved virtual link—i.e., minimum guaranteed bandwidth and/or maximum bandwidth. Such partitions can be applied on a per-application basis (protecting and/or capping bandwidth for all traffic associated with an application) or a per-user basis (protecting and/or capping bandwidth for a particular user). Furthermore, U.S. patent application Ser. No. 09/198,090, identified above, teaches methods and systems for automatically discovering and classifying network traffic to facilitate management of network bandwidth.
As the various applications, services and functionality deployed across computer network environments evolve, network traffic identification functionality must be augmented and/or modified in order to recognize new network traffic types or changes to existing network traffic types. Administration of bandwidth management devices to ensure that they have been upgraded to execute the latest traffic identification functionality, however, can become quite cumbersome. A network administrator often tasked with a variety of time-consuming responsibilities has to be notified or otherwise made aware of updated traffic identification functionality. The network administrator then must take the time to evaluate whether the updated functionality is worth the time and effort to install on the bandwidth management devices within the administrative domain. Finally, assuming the network administrator decides to upgrade the software of the bandwidth management device(s), he or she must then install the upgrade on the bandwidth management device(s). Indeed, the difficulties associated with bandwidth management device upgrades is exacerbated for network administrators managing multiple bandwidth management devices within the same administrative domain. Often, such administrative domains include multiple bandwidth management devices running different software versions and/or builds, requiring the network administrator to locate, download and install multiple, version- and/or build-specific upgrades. Given the foregoing, network administrators may decide that the effort to upgrade bandwidth management functionality on their networks may not be worth the time and effort, especially if the network administrator perceives that such bandwidth management devices are functioning adequately. This circumstance creates the undesirable trade off between the convenience or time-savings associated with not upgrading the bandwidth management devices versus the resulting decline in the capabilities of such devices as time progresses and the characteristics of network traffic evolve.
In light of the foregoing, a need exists in the art for methods, apparatuses and systems that facilitate the distribution of updated traffic identification functionality to bandwidth management devices. Embodiments of the present invention substantially fulfill this need.